Vehicle resource management system

ABSTRACT

A vehicle resource management system for an electric vehicle includes programmable electronic controls integrated into the vehicle configured to consume resources during operation such as electricity, fossil fuels, and the like. Also included as part of the resource management system is an operational algorithm which communicates with the electronic controls to evaluate the driving range available for the available resources. The operational algorithm also receives and processes a plurality of trip variables, at least some of which may be entered by a user using a user interface.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of PCT/US2014/069264 filed Dec. 9,2014 which claims the benefit of U.S. Provisional Patent ApplicationSer. 61/916,412 filed Dec. 16, 2013, both of which are herebyincorporated by reference.

BACKGROUND

The present invention as exemplified by this disclosure relates to thecontrol and management of vehicle resources which restrict a vehicle'srange. One concern with electrical vehicles is the state of charge ofthe battery relative to the trip which is contemplated. Depending on thetrip variables of the specific route, including the distance, the issueor at least one issue, is whether the state of charge of the battery issufficient to complete the trip and reach the intended destination.Another consideration is whether a charging station or chargingcapability will be present along the route and/or at the destination.The same types of issues arise with fossil fuel powered or hybridvehicles with regard to the range of the vehicle and the relativelocation of refueling stations.

With regard to electric vehicles, this description is focused on, butnot limited to, relatively shorter trips where a full battery chargewould likely enable the electric vehicle to reach the intendeddestination. Something less than a full charge thus becomes problematic.If the existing charge is not sufficient for the electric vehicle toreach the intended destination, then an additional charge (i.e.,recharge) would be required or it would be necessary to either alter thedestination or alter the route or alter the manner of use of the vehicleor some combination of all of these. Shorter trips are less of a concernwith fossil fuel powered vehicles or hybrid vehicles although theseconcerns are considered as well. One option for the electric vehicle isto detour from the intended route in order to reach a charging stationor a charging vehicle. This alternative is intended to restore some orall of the charge on the battery, presumably to a level which issufficient to allow the electric vehicle to get back on its intendedroute and reach the desired destination.

Although this description of what might occur is put into the context ofa relatively shorter trip, such as to and from work, much longer tripswould likely always require one or more stops at a charging station or avisit from a charging vehicle, based on the anticipated range for afully charged electric vehicle. Nevertheless, even with such longertrips, there is value in being able to assess the remaining range forthe vehicle in order to try and limit the number of recharging stopswhich have to be made during this longer trip in order to reach thedestination. The “destination” could include a charging station, acharging vehicle, or a fossil fuel dispensing station.

Accepting that it would be beneficial to the use of a vehicle to know,or at least be able to predict with some likelihood of success, theremaining driving distance or range based on the state of charge orremaining fuel, one question is how to make this driving rangedetermination. A related question is how to make the prediction ordetermination more accurate and reliable. With regard to electricvehicles, a related question is how one might vary or modify the mannerof use of the electric vehicle to improve the likelihood of reaching theintended destination with the available charge on the battery. A numberof variables can and will affect the driving range. These variablescorrespond to the vehicle specifics, the driving habits of the user, thespecifics of the route selected and external conditions such as trafficand weather. One challenge is to try and identify all of the importantvariables which may affect driving range of the electric vehicle basedon the state of charge any instant in time. Another challenge isassigning a “weight” to the most relevant variables, i.e., those withthe greatest effect on the driving range of the electric vehicle.

The present invention, as exemplified by this disclosure, is directed tothe design, development and application of a vehicle resource managementsystem which is preferably used by an electric vehicle and by theoperator of the electric vehicle as a way to help predict theprobability of the vehicle reaching the intended destination given itscurrent charge. The algorithm is based in part on current trip variablesand changes to those variables as the trip proceeds. The algorithm isalso based in part on historical variables as might be derived from aparticular route which is repetitive. A wide variety of otherinformation from other sources or resources is also contemplated for usein the algorithm.

Use of the disclosed algorithm, as integrated into the controls of theelectric vehicle, provides a means for drivers of electric vehicles tohave additional information regarding the projected driving range. Thisis the driving range remaining for the electric vehicle based on thestate of charge on the vehicle battery (or batteries) at that instant intime. Obviously, this projected driving range may change eitherincreasing or decreasing, as the trip continues, based on the changingvariables. Other driving adjustments, control functions and controloptions are offered by the disclosed algorithm.

SUMMARY

A resource management system for an electric vehicle includesprogrammable electronic controls integrated into the electric vehicle,the electric vehicle including a battery. Also included as part of thevehicle resource management system is an operational algorithm whichcommunicates with the electronic controls to evaluate the driving rangeavailable for the existing charge on the battery. The operationalalgorithm receives and processes a plurality of trip variables. Includedas well is a dynamic braking control algorithm to efficiently managebraking function.

Further forms, objects, features, aspects, benefits, advantages, andembodiments of the present invention will become apparent from adetailed description and drawings provided herewith.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a component diagram indicating vehicle features as well assubsystems included in the vehicle resource management system describedand disclosed.

FIG. 2 is a schematic illustration of one example of system componentsand data flow which may be included in a vehicle controller shown inFIG. 1.

FIG. 3 is a flow chart describing further one example of actions takenby the vehicle controller from FIG. 2 in acquiring, processing, storing,and retrieving data to manage system resources.

FIG. 4 is a flow chart describing one example of the actions that may betaken by the vehicle controller in FIG. 2 to assess and apply vehiclebraking.

FIG. 5 is a flow chart describing another example of actions that may betaken by the vehicle controller in FIG. 2 to assess and apply vehiclebraking.

DETAILED DESCRIPTION

For the purpose of promoting an understanding of the principles of theinvention, reference will now be made to the embodiments illustrated inthe drawings and specific language will be used to describe the same. Itwill nevertheless be understood that no limitation of the scope of theinvention is thereby intended. Any alterations and further modificationsin the described embodiments, and any further applications of theprinciples of the invention as described herein are contemplated aswould normally occur to one skilled in the art to which the inventionrelates. One embodiment of the invention is shown in great detail,although it will be apparent to those skilled in the relevant art thatsome features that are not relevant to the present invention may not beshown for the sake of clarity.

The following disclosure describes in detail various range predictioncalculations and predictions based on various inputs specific to thecurrent state and expected performance of an electric vehicle. However,as will be understood by one of ordinary skilled in the art, theprocedures for predicting vehicle range for fossil fuel powered vehiclebased on the principles discussed in the following detailed descriptionare essentially the same. Although the description may at various pointsexplicitly discuss electric vehicles, the use of fossil fuels in ahybrid vehicle or in a vehicle that uses only fossil fuels is alsoenvisioned where applicable regardless of whether specific explicitmention is made of these other energy forms at each step of thedisclosure. As used herein, the term “vehicle” is intended to beinclusive of all types of vehicles including autonomous, semi-autonomousand non-autonomous.

FIG. 1 illustrates at 10 an example of systems, devices, features,components, and various other aspects of a vehicle resource managementsystem. These various features and aspects are included is a vehicle 21operating as data inputs and outputs for the vehicle resource managementsystem disclosed below. The inputs and outputs indicated are notexclusive given that vehicle technology is constantly evolving andchanging. Therefore, other aspects and systems of vehicle 21 involvingvehicle operations and resource consumption may be useful and areenvisioned as well.

Vehicle 21 is shown with various aspects, features, and componentsseparated into lists. Operational components 24 includes basic systemsand aspects of vehicle 21 along with other features and components thatprovide functionality for the operator. Examples of operationalcomponents 24 are useful for vehicle operation and may exchangeinformation with a vehicle controller 34 or with other systems includedin the vehicle resource management system. These interactions may inturn cause vehicle controller 34 to send signals to one or more of theoperational components 24 adjusting their behavior to achieve certaingoals such as increased efficiency or various other operator preferredoutcomes. These and other aspects are described in greater detail below.

Vehicle controls 27 includes examples of vehicle controls the vehicleoperator may interact with to control vehicle 21. Other controls may beincluded or described in greater detail below. Data regarding theposition and overall state of these controls may also be exchanged withvehicle controller 34 or with other components within the vehicleresource management system as described in greater detail below.

Communication and sensor devices 31 are also shown indicating someexamples of various data collection devices, sensors, and systems.Communication and sensor devices 31 may communicate with outside systemsby various means such as by sending or receiving radio transmissionsfrom, for example, satellites, a cellular telephone network, and thelike. Communication and sensor devices 31 may interact with operationalcomponents 24 to collect data such as fuel or battery charge remaining,tire pressures, power output of the internal combustion engine, and thelike. This interaction may occur via wired or wireless connectionsbetween sensor devices 31, and one or more operational components 24.Communication and sensor devices 31 provide vehicle controller 34 andother aspects of the vehicle resource management system with data usefulfor making decisions as described in detail below.

Other aspects, features, components, sensors, and systems of vehicle 21may also be used by various embodiments of the vehicle resourcemanagement system depending on the unique features of the particularvehicle and the particular activities it is engaged in. It should benoted that although vehicle 21 may appear as a mid-size car or sedan, nolimitation on the make, model, size, or any other particular vehicleattribute should be implied by the drawing as the drawing is exemplaryonly rather than restrictive. For example, vehicle 21 may appear to beillustrated as having four doors and two headlights. However, vehicle 21may be a motorcycle having no doors and only one headlight. Vehicle 21may be a mini-van, light truck, school bus, multi-axle semi-tractor withor without a trailer, delivery van, compact car, motorcycle, or sportscar to name a few non-limiting examples.

FIG. 2 illustrates in schematic form further detail of one example ofcomponents that may be included in a vehicle controller 34. A vehiclecontroller shown at 34 includes a user interface 37 for use by a user 36such as a driver or other occupant of vehicle 21, a vehicle controlinterface 41 for interfacing with other vehicle systems, a data store50, a processor 46, and an analytics agent 53. User interface 37 acceptsuser input from user 36 such as destinations and possibly other driverspecific parameters affecting vehicle performance. User interface 37 canalso be used by user 36 to signal processor 46 to calculate a rangeprediction based on resource availability and consumption, or optionallyto request range predictions recur repeatedly at predetermined intervalsuntil otherwise directed by the user or the system.

Processor 46 may make a range prediction by taking any of a variety ofactions involving the current state of the vehicle and its location withrespect to a selected destination. For example, a range predictioncalculation may include reading data from data store 50, calculating thepredicted probability of reaching a destination entered by user 36 usinguser interface 37, writing the results of the calculation back to datastore 50, and updating the user interface 37. User interface 37 may thenbe configured to present the user with various energy consumptionrelated options offering the user opportunities to input subsequentselections to refine the prediction, make a new prediction, or act onthe current prediction. Where the user decides to act on the currentprediction, vehicle controller 34 may then assemble a sequence ofcommands or signals for controlling the behavior of the vehicle whichare readable by vehicle 21 and pass them to the various vehiclesubsystems using vehicle control interface 41. Vehicle control interface41 can interact with various systems in vehicle 21 to collect data aboutthe vehicle, such as the data indicated in FIG. 1, or to pass commandsto the systems in vehicle 21 modifying the behavior of the vehicle asdetermined by the algorithm.

As illustrated in FIGS. 2 and 3, the algorithm operating in vehiclecontroller 34 can make predictions using data received from numeroussources, some examples of which are shown. For example, a vehicle datacollector 57 collects information from the vehicle itself. On one hand,this information may include various information related to batterydrain such as the present electrical current draw on the battery(measured in Amperes) and the potential difference across the batteryterminals (measured in Volts). In some vehicles, the main battery may becomposed of multiple individual cells coupled together in series or inparallel, or in a series/parallel arrangement, in which case the currentand potential difference data collected by vehicle data collector 57 mayinclude current and potential difference information for each cell, orfor groups of cells within the main battery.

Resource consumption information may also include flags, signals, orother indicators indicating whether and to what extent particularsubsystems or accessories are active such the windshield wipers, airconditioner or heater, head lights, day time running lamps, radio orentertainment center, cell phone, laptop computer, or other charger ordocking station, cigarette lighter, electric rear window defrosters,electric rear view mirror defrosters, seat heaters, or proximity, rangefinding, or anti-collision sensors. Vehicle data collector 57 may alsoreceive individual current and/or voltage data indicating drain on thebattery or overall power consumption of each of these accessories orsubsystems.

In the hybrid or fossil fuel context, vehicle data collector 57 mayreceive other information like type of fuel or fuel composition,quantity of fuel remaining, recent and/or current burn rate, and fuelmixture. Vehicle data collector 57 may also collect and processinformation about the density of air entering the engine, thecomposition of the fuel air mixture being burned, and the composition ofresulting exhaust gases, any one of which alone, or used together incombination, may be helpful in calculating the probability of reaching agiven destination following a particular route or set of routes.

As the trip progresses, changes may occur like new direct input from theuser, changes in the environment, and the like. The user may, forexample, activate or deactivate a system that substantially increases ordecreases load on the battery or the current fuel burn rate such as aheater, air conditioner, head lights, or seat heaters. In anotherexample, the user may increase or decrease the average rate of speed, orbegin to drive more smoothly or more erratically resulting in a changein the extent and/or frequency of speed and direction changes. Vehicledata collector 57 may therefore be optimized to monitor vehicle statusinformation and update data store 50 so as to provide processor 46 withinformation from which to make a trip prediction. In one example,vehicle data collector 57 can read or sample data values representingthe state or recent behavior of various vehicle systems at a very highnumber of samples per second saving the collected data values to datastore 50. For example, vehicle data collector may read and store some orall of the available vehicle data values more than several hundred,several thousand, or tens of thousands of times a second generating alarge quantity of stored data for analysis. Another example of vehicledata collector 57 monitors vehicle 21 reading, sampling and storingvehicle data collecting more infrequent snapshots of all availablevehicle data values at intervals greater than every hundredth of asecond, greater than every second, greater than every 10 seconds,greater than every 30 seconds, or more.

It may, however, be cost prohibitive to implement a real-time, ornear-real-time monitoring system collecting data from all the vehicle'ssystems at thousands or millions of times per second. Other examples ofvehicle data collector 57 include an event based or interrupt drivendata collector 57 which writes vehicle data to data store 50 whenanother data collector, a vehicle subsystem, or other device notifiesthe vehicle data collector 57 of an event that the vehicle datacollector 57 is programmed or configured to respond to. For example,rather than constantly saving a data value corresponding to the currentdraw caused by the headlights a predetermined 10 times per second,vehicle data collector 57 may only read or sense and store these datavalues after it has received a signal from vehicle 21 indicating theheadlights have been activated. Other similar events that may bemonitored include, but are not limited to, activation of the vehicle'sheater, rear window defroster, seat heaters, air conditioner,entertainment center, or any other events which may increase or decreasethe rate at which available vehicle resources such as battery charge andfuel are being consumed. In another example, it may only be desirable tostore time and interval data indicating which systems were active, forwhat interval of time, and the high, low, and average voltage, current,and power usage rather than storing individual values. These embodimentsof vehicle data collector 57 can reduce the storage capacity required tomaintain data store 50 but may also result in less accurate predictionsbecause of a corresponding reduction in the available sample size of thecollected data values. It may also be advantageous in some embodimentsof data store 50, vehicle data collector 57, or both, to implement adata compression scheme for reducing the physical or virtual storagespace required to maintain data store 50.

Geospatial positional information including latitude and longitude ofthe vehicle may be gathered by a location data collector 60 and writtento data store 50. One example of location data collector 60 uses aGlobal Positioning Satellite (GPS) system which can operate togetherwith a GPS enabled device coupled to location data collector 60 toprovide updated location data. As with the vehicle data collector 57,location data collector 60 may be implemented to sample or read locationdata values at a slower rate that is greater than every second, orgreater than every 10 seconds, or at a much faster rate generating amuch higher quantity of data such as greater than a thousand times asecond, or greater than ten thousand times a second to name just a fewexamples. Data compression may also be useful as well to keep thephysical or logical size of the location data saved in data store 50from becoming unmanageably large.

The GPS system including, antenna, radio transmitter, and or radioreceiver may either be part of the original equipment integrated intovehicle 21 by the manufacturer or added separately at a later time. Inanother example, the GPS system and radio transmitter or receiver areintegrated into a single unit such as a cell phone, smart phone, orportable computer which can be connected to location data collector 60through a wired or wireless connection. Another example of location datacollector 60 uses a radio transceiver to triangulate the position ofvehicle 21 using radio signals such as from a cellular telephone networkor similar source. These radio signals may be received and/ortransmitted by a smart phone, cell phone, tablet computer, or similarlyequipped cellular communication device capable of sending and/orreceiving signals. For example, user 36 may dock or otherwise couple asmartphone to vehicle controller 34 and use the GPS features within thecell phone to obtain positional information to be used by the predictivealgorithm.

Regardless of how the positional information is acquired, location datacollector 60 acquires the positional data and writes the information todata store 50. Using this data, processor 46 can accurately modelrelationships between locations and resource consumption such as batterydrain and fuel consumption. One embodiment of location data collector 60writes a positional record whenever a positional fix is acquired savingthe best-known latitude and longitude, along with a timestamp. Thisembodiment gives processor 46 accurate location data but may also resultin a physical or logical size requirement for data store 50 that isprohibitively large and/or expensive. In another example, location datacollector 60 acquires the position of vehicle 21 at regular intervalssuch as about every half second, every second, or every five seconds, orperhaps more often or less often. Location data collector 60 may writethis data to data store 50 each time it is received, or write the datato data store 50 at a second separate predetermined interval, and thenperhaps only if the positional data is above a particular qualitythreshold. Any device or system coupled to vehicle 21 that is capable ofdetermining its location on the earth, or relative to other landmarks isenvisioned.

Positional information, as well as other data useful for predictingresource consumption, may also be correlated to map data to furtherdevelop and refine the disclosed resource consumption calculations. Mapdata may be gathered by a map data collector 62 and written to datastore 50 where it can be accessed by the processor 46 and other moduleswithin vehicle controller 34. One example of map data collector 62obtains map information from remote computer systems. These remotecomputer systems can include servers networked together using a computernetwork such as the internet which may be coupled to the map datacollector using a wired or wireless network connection. For example, mapdata collector 62 may use an internet connection made available by asmart phone, cellular phone, or other cellular enabled device such as atablet or laptop computer coupled to vehicle interface 34. Map datacollector 60 may use the coupled device's cellular, Wireless LocalAccess Network connection (WLAN also known as “Wi-Fi”), or othercomputer network connection to obtain map information from remotecomputers.

Map data may include graphical representations for display to user 36,perhaps on user interface 37, or computer machine readablerepresentations encoded for integration, storage, and analysis forinforming decision making by processor 46 or any other module within orconnected to vehicle controller 34. As with the vehicle data collector57, location data collector 60 may be implemented to sample or readlocation data values at a slower rate that is greater than every second,or greater than every 10 seconds, or at a faster rate generating alarger quantity of data such as greater than a thousand times a second,or greater than ten thousand times a second to name just a few examples.In another example, map data may be considered relatively static and mayonly be updated daily, weekly, monthly, or even less often. Datacompression may also be useful as well to keep the quantity of map datafrom overwhelming the capacity of data store 50.

The collected map data may include data representing nodes, locations,or destinations as well as paths with corresponding path locations. Thepaths and nodes may correspond to existing physical locations such asstreets, roads or highway intersections, buildings, landmarks, points ofinterest, restaurants, entertainment venues, homes, businesses,government facilities, and the like. Nodes and paths may also includeuser defined nodes or user defined data associated with existing nodesindicating additional details or places of interest. For example, a usermay use a web browser interacting with a remote computer over a computernetwork such as the internet to define particular locations as being“home”, or “school”, or “office” and the like. These locations may bestored by the remote computer and provided to map data collector 62 overa wireless or wired network connection to aid in the disclosedcalculations. Various graphical indicators may also be displayed in agraphical user interface on user interface 37 corresponding to the nodes(locations) and paths in the map data to aid user 36 in making choiceswith respect to routes and destinations. User interface 37 may also beconfigured to accept user input defining nodes, paths, or additionalinformation about a node or path provided from a remote computer aswell. This additional information, provided using user interface 37, aremote computer as disclosed above, or by another means may replace orbe added to map data received from a remote source to provide aid in theprediction of resource consumption.

The additional data about nodes or paths (whether provided by the useror by another system) may include data such as elevation, grade, type ofroad surface, number of lanes, direction of travel, the existence andarrangement of traffic lights or other signals, a direction of travelpermitted along the path, and whether traffic flow reverses along agiven path or through a particular node at one time of day with respectto a second time of day (e.g. traffic flows west-bound during themid-day and evening hours to move traffic out of town, and east-bound inthe opposite direction in the morning to move traffic into town). Mapdata may also include information about when particular traffic lightsflash yellow in the direction of one path and flash red in the directionof the intersecting path during off peak-hours switching to operate in afour-way red-yellow-green pattern at other times. Also included may bedata regarding whether a traffic signals are triggered by the presenceof vehicle traffic using a vehicle sensor triggered by vehicle proximityor weight, or are operated on a timer configured to control andcoordinate a series of traffic signals to change signals in a sequenceor pattern. Additional data may also include frequently traveled routes,or user selected preprogrammed routes. Nodes and paths may also includecost information such as whether a toll is collected at a particularnode or collected after traversing a particular path.

Some or all of the map data collected by map data collector 62, as wellas other map related data used by controller 34 may be obtained from aGeographic Information System (GIS) provider such as a government, acartographer or company specializing in cartography, or from aninternet-based service through a web browser, web service, ApplicationProgramming Interface (API), or other similar source. Examples of aremote web-based or API approach include map data provided by Google,Inc., based in Mountain View, Calif. and include Google Earth or GoogleMaps. These APIs and services currently include Google Places, GoogleStreet View, and the Google Maps API for Business. Other examples ofcommercially available mapping services or software are provided by theMicrosoft Corporation based in Redmond, Wash., and include software andweb services such as the MapPoint® map software and maps or map dataprovided by the Bing® search engine, or map data provided using theMicrosoft® Bing® Maps Platforms APIs.

Topographical data related to possible routes of travel is collected andstored in data store 50 by a topographical data collector 64.Topographical data is used by processor 46 to model changes in resourceconsumption based on significant variations in elevation along a route.Topographical data may be used in relation to map, vehicle, weather, andother data in data store 50 as well. For example, an electric vehiclewill typically expend more energy driving up a long incline but may thenreclaim some or all of that energy using regenerative braking on a downslope.

In one example, a topographical data collector 64 is connected to one ormore sensors such as an altimeter or similar device operable to detectsmall changes in elevation. Such a device may be part of the originalequipment provided by the manufacturer of vehicle 21, retrofitted later,or integrated into another device such as a portable altimeter orcoupled to vehicle controller 34 by a wireless or wired connection. Thistype of data has the advantage of providing processor 46 with data thatcorrelates to main battery, fuel, or other energy usage over aparticular route or route segment that can correspond to nodes and pathscollected by the map data collector 62. The altimeter data may besampled like the location and map data previously mentioned at either ahigh rate (e.g. tens, hundreds or thousands of times a second, or more)for a more accurate representation of altitude changes, or at a lowerrate (e.g. every second, every ten seconds, or even less often) to savespace in data store 50. In another embodiment, the altimeter data issampled as previously mentioned, but data is not saved to data store 50unless the change in elevation since the last sample was stored isgreater than a predetermined threshold, for example, greater than 10feet, greater than 50 ft., or greater than 100 feet or more.

One example of topographical data collector 64 retrieves topographicaldata for a given route as the road is traversed. Another example oftopographical data collector 64 retrieve an initial set of topographicaldata from an external or remote data source such as a remote computeraccessible via a wired or wireless computer network connection.Topographical data collector 64 may retrieve relevant topography data topreload the data store 50 with topographical information correspondingto the route chosen or the general area surrounding the chosen route ordestination. In another example, topographical data collector 64preloads existing data from a remote source via a computer network tomake initial calculations and then senses changes in altitude using analtitude sensing device as the vehicle proceeds along the route therebyupdating the preloaded data for increased accuracy. In yet anotherexample, topographical data collector 64 acquires elevation data from amobile device such as a cell phone, smart phone, Personal DigitalAssistant (PDA), tablet computer, or laptop computer connecting to aremote computer using a wired or wireless network to collect and storealtitudes at particular locations, or along paths between locations.

The topographical data collected may also include or consist of changesin altitude at one location relative to one or more other locations. Thetopographical data retrieved from a remote source may be included withmap information retrieved using map data collector 62. Topographicaldata may also be stored and retrieved separately from map data retrievedor stored in data store 50. However, map data may be used by someembodiments of topographical data collector 64 to query a remote systems(or data store 50) for specific topographical information to obtain datarelated to a route, a number of potential routes, or a geographical areaincluding a route or a number of potential routes. These devices couldeither be connected to topographical data collector 64 or serve as thedata collector themselves and be directly connected to data store 50.

Vehicle controller 34 can also collect weather data using a weather datacollector 70. As with vehicle, location, and map data discussed above,weather data can be stored in data store 50 for analysis by processor 46to model changes in the rate of consumption of vehicle resources causedby weather related phenomena. Pertinent weather data may include windspeed and direction, temperature, visibility, cloud cover, sunrise,sunset, and dew point. Whether data may also include precipitationinformation such as type of precipitation, and the amount ofprecipitation deposited over a predetermined period of time such as perminute, per hour, per day, and the like.

In one example, weather data collector 70 accesses weather data from oneor more remote computer systems providing weather data from databasesaccessible through one or more wired or wireless networks such as theInternet. The wired or wireless network connection may be supplied by amobile device such as a smart phone, laptop computer, and others asdiscussed above. Another example of weather data collector 70supplements weather data accessed from a remote database with sensorreadings taken from vehicle sensors as the vehicle traverses a selectedroute. Examples of types of data that may be collected by vehiclesensors include, but are not limited to, temperature, air pressure,visibility, and humidity.

Sampling rates of the various sensors collecting weather data may varywidely. As with previously discussed data collectors, sampling may occurat widely varying predetermined intervals such as hundreds or thousandsof times a second or every second, every 5 seconds, or more. Anysuitable sampling rate is envisioned and as noted above with vehicle,location, map, and topographical data collectors, the sampling rate mayvary significantly and is not limited to a specific range. Similar toprevious data collectors discussed, some examples of weather datacollector 70 may optimize storage space in data store 50 by writingweather data to data store 50 when one or more of the valuesrepresenting a particular atmospheric condition changes with respect toone or more recent samplings or readings, or changes with respect to apredetermined baseline value. In another example, weather data collector70 may also economize storage space in data store 50 by accessingweather data from a remote database and maintaining it in temporarystorage within data store 50 or a memory in controller 34 while resourcepredictions are calculated. In this example, once resource predictionsare made and the calculations are completed, weather data may be deletedand retrieved again at a later time after a predetermined interval haspassed (e.g. 30 or 60 minutes).

A traffic data collector 73 can collect traffic and road condition dataand write it to data store 50 enabling processor 46 to make resourcepredictions based on traffic patterns and road conditions. Oneembodiment of traffic data collector 73 acquires traffic relatedinformation for the chosen route from a remote database accessiblethrough a computer network such as the internet and saves traffic datato data store 50 for analysis by processor 46. Traffic and roadconditions may include the existence of temporary obstructions to theflow of traffic such as construction zones, utility work, lanerestrictions, traffic accidents, emergencies, and the like. It may alsoinclude traffic flow rates where available indicating the rate at whichtraffic is traveling over a given segment of one or more routes orpotential travel routes. As with other data collectors mentioned abovesuch as topographical and whether data collectors, traffic datacollector 73 may access location data and map data, and possibly otherdata as well, from data store 50 to query for traffic data specific tonodes or locations, and paths or segments along a proposed route.

In another example, traffic data collector 73 reads positional data fromdata store 50 as the route is traversed and uses the positionalinformation to calculate path, segment, or route timing informationwhich can be stored in data store 50. In this way, route specific datacan be created indicating areas where the average speed may change, orwhere traffic frequently stops and for how long. By repeatedlytraversing substantially the same routes, traffic data collector 73 candevelop data regarding traffic flow, number of stops, length of stops,average speed, and overall resources required for a given path, routesegment, or route. In another example, traffic data collector 73combines accessing traffic flow patterns from a remote database withdata collected over time. In yet another example, the traffic datacollector 73 is installed in emergency vehicles and is configured tocommunicate with automated traffic management systems to obtainadditional data about, for example, traffic signals that can becontrolled by vehicle controller 34 to modify traffic flows along aproposed route or route segment.

Analytics agent 53 as shown in FIG. 2 analyzes historical data tocalculate the accuracy of the predictions made by processor 46. In oneexample, analytics agent 53 analyzes the results of past predictionssearching for anomalies in predictions on particular routes, or routesegments where the results are predictably incorrect for particularcombinations of traffic, weather, vehicle, and topography variables.Analytics agent 53 can also calculate and write to data store 50 a setof modifiers that can be applied by processor 46 to future predictionsto reduce or eliminate the difference between the predicted results andthe actual results. In another example, analytics agent 53 increases theaccuracy of resource prediction calculations performed by processor 46by connecting to a remote server, and uploading some or all of the dataused by processor 46 to make resource predictions. This data can includevalues representing predicted resource consumption and actual resourceconsumption for a particular route, route segment, destination, orintermediate node or location. The data may include vehicle, location,map, topographical, and whether data, and any other data processed byprocessor 46. The remote server may then process the data received andusing it to develop or change the algorithms used by processor 46 tochange its functionality, preferably to reduce or eliminate differencesbetween actual results for a given route and calculated predictions madeby processor 46. In one example, the internal algorithms executed byprocessor 46 may be changed using software updates such as a firmwareupdate and the like. Analytics agent 53 may then download the upgradedsoftware and install it in processor 46.

Processing of vehicle, location, map, topography, weather, traffic, andany other data used in predicting resource usage for vehicle 21 can beexecuted by processor 46. Using algorithms like those disclosed,processor 46 can analyze complex relationships between the current andfuture resource needs of the various vehicle systems to determine alikelihood of reaching a selected destination before available resourcesare fully expended (e.g. vehicle 21 runs out of fuel or discharges it'sprimary battery). Processor 46 may execute these algorithms more thanseveral hundred, or several thousand times a second, perhaps more thanseveral million times a second. Similarly, processor 46 may beprogrammed or controlled by an external controller to execute thedisclosed algorithms at larger intervals such as intervals greater thanevery half second, greater than every five seconds, or greater thanevery minute to name a few non-limiting examples. Processor 46 mayexecute resource prediction more often for more accurate predictions, orless often to conserve processing resources such as power consumed inoperating the processor or storage space in data store 50.

Considering further implementation specifics, the resource allocationsystem and method can operate as software executing on processor 46which may include one or more physical or virtual processors or CentralProcessing Units (CPUs) and one or more types of memory. Each memory caninclude a removable memory device. Each processor may be comprised ofone or more components configured as a single unit such as arithmeticunits, controllers, and the like. Alternatively, when of amulti-component form, a processor may have one or more componentslocated remotely relative to the others. One or more components of eachprocessor may be of the electronic variety defining digital circuitry,analog circuitry, or both. In one embodiment, each processor is of aconventional, integrated circuit microprocessor arrangement, such as oneor more PENTIUM, i3, i5 or i7 processors supplied by INTEL Corporation,Santa Clara, Calif. USA. In another example, the processor may be aprogrammable microcontroller such as the Cortex-M4F, Cortex-M3, orCortex-M0 commercially available from STMicroelectronics of Geneva,Switzerland. Any suitable circuit capable of executing algorithms forpredicting resource consumption and/or the likelihood of arriving at aselected destination may be used.

Each memory, whether part of processor 46, data store 50, or foundelsewhere in controller 34 may be any suitable form of acomputer-readable storage device. Each memory may include one or moretypes of solid-state electronic memory, magnetic memory, or opticalmemory, just to name a few. By way of non-limiting example, each memorymay include solid-state electronic Random Access Memory (RAM),Sequentially Accessible Memory (SAM) (such as the First-In, First-Out(FIFO) variety or the Last-In-First-Out (LIFO) variety), ProgrammableRead Only Memory (PROM), Electronically Programmable Read Only Memory(EPROM), or Electrically Erasable Programmable Read Only Memory(EEPROM); an optical disc memory (such as a DVD or CD ROM); amagnetically encoded hard disc, floppy disc, tape, or cartridge media;or a combination of any of these memory types. Also, each memory may bevolatile, nonvolatile, or a hybrid combination of volatile andnonvolatile varieties.

Processor 46 may be embodied as a “computer” in the generic sense andmay be a single, physical, computing device such as a desktop computer,a laptop computer, microcontroller mounted to a Printed Circuit Board(PCB) with other supporting circuits, or may be composed of multipledevices of the same type such as a group of processors or computersoperating as one device in a networked cluster, or a heterogeneouscombination of different computing devices also linked together by anetwork and operating as one computer. Thus processor 46 may be composedof one or more physical computing devices having one or more physicalprocessors or “processing cores” and memory as described above.Processor 46 may also be enclosed within a single housing or enclosure,or if so constructed, its component parts may be organized within aplurality of enclosures housing separate component parts or groups ofparts working together to comprise processor 46.

Processor 46 can be coupled to a display for displaying user interface37, for example, controller 34 may include an integrated display or becoupled to a display device located in a separate housing in anotherpart of vehicle 21. Likewise, displays may be of the same type, or aheterogeneous combination of different visual devices. Although notshown, user interface 37 may also include or be coupled with one or moreoperator input devices such as a keyboard, mouse, capacitive, inductive,pressure sensitive, or any other sort of touch screen, laser or infraredpointing device, or gyroscopic pointing device to name just a fewrepresentative examples. Controller 34 may also include ports forconnecting one or more other output devices such as data transmissiondevices like network adapters or diagnostic devices, other computers,printers, plotters, and the like. As such, various display, input andoutput device arrangements are possible.

The data and operating logic of controller 34, processor 46, and theother elements shown in FIG. 2 can be embodied in signals transmittedover a network, in programming instructions, dedicated hardware, or acombination of these. Thus communications between elements of controller34 or with remote computers as discussed above can be achieved byvarious means such as a wireless or wired Local Area Network (LAN),Municipal Area Network (MAN), Wide Area Network (WAN), such as theInternet, a combination of these, or any other suitable computernetwork.

External data sources, some of which are described above, may also beconnected to processor 46 via data access devices connected to thesesame communications links, or by data access devices providing data byother means such as via nonvolatile storage devices such as DVD orCD-ROM, flash memory devices, and the like. It shall be appreciated thatin alternate forms a user may submit requests for range prediction,input relevant data, and view reports generated by the system as well asother relevant vehicle information on computing devices such as a userinterface 37, PDAs, Blackberries, iPhones, iPads, smart phones or tabletcomputers, to name just a few illustrative examples.

FIG. 3 illustrates example actions that may be taken by processor 46 incalculating the probability of reaching a selected destination using theresources available to vehicle 21. An initialization action 80 may beexecuted which can include removing remnants of previous probabilitycalculations, performing diagnostic self-evaluations, and determining ifrelevant data sources and/or sufficient data storage is available.

Driver specific parameters may also be loaded (83) which may be appliedto the upcoming calculations. Driver specific parameters includeparameters selected and maintained for individual drivers such as thedriver's aggressiveness, the driver's preferred interior temperature,whether the driver prefers listening to the radio, MP3 player, or otherentertainment devices, whether and to what extent the driver prefers tohave the seats warmed, and other similar preferences. Driver specificparameters may also include the number of alternate routes controller 34should calculate resource predictions for using a selected finaldestination. For example, user interface 37 may be used to request aprediction of the resources likely to be consumed traveling two, three,five, or more alternate routes to a given destination. In anotherexample, driver specific parameters may include a route preference suchas a preference for taking a more scenic route, a desire to avoid aparticular neighborhood, a desire to avoid or traverse a particularsection of interstate, or an explicit requirement to include aparticular node or location or series of locations in the route.

Controller 34 can also read vehicle state information (85) from one ormore of the systems for devices shown in in FIG. 1 and discussed above.Vehicle state information can include any number of variablesrepresenting the current state of the operating vehicle such as currentflow from the main battery, tire pressure, engine temperature, fuelremaining, whether the seat heaters are activated and to what extent,how many occupants are in the vehicle, vehicle speed, and what gear thetransmission is in to name just a few nonlimiting examples. Any numberof parameters representing current vehicle state may be part of vehiclestate information (85), including, but not limited to, those parameterscollected by vehicle data collector 57.

Controller 34 can also read available weather data from data store 50and generate a weather model (88). The resulting weather model 107 canmaintain values representing the usage of the vehicle's energy resources(e.g. main battery, fossil fuel, fuel cells, super capacitor, and thelike) as a function of weather, location, and time. This data may becollected from any available source including weather data collector 70.One embodiment of generating a weather model (88) may include segmentingthe route, predicting weather related events likely to occur for eachparticular segment during the course of the trip, and using thisinformation to calculate resource consumption resulting from theseweather events. For example, weather data retrieved by weather datacollector 70 may indicate clear and dry conditions for all segments ofthe route except the last eight which include a 50 percent chance ofrain. Weather model 107 will therefore indicate a 50 percent chance ofincreased battery load due to equipment activated because of rain andpoor visibility such as windshield wipers, head lights, running lights,fog lamps, climate control to adjust cabin temperature and humidity, orcollision avoidance or range finding systems if available.

In another example, if the weather at the beginning of the trip involvedsteady rain, and the forecast stated a 50 percent chance of rain overthe last eight segments of the route, generating a weather model 88might result in a weather model 107 including a 50 percent chance ofreduced battery drain over the last eight segments due to thedeactivation of systems likely to be operated during periods of rain andpoor visibility such as those mentioned above.

In another example, if weather data collector 70 indicated a 46 percentchance that three segments of the route will have snow-covered icyroads, then generating a weather model (88) might result in a weathermodel 107 having three segments with a 46 percent chance of increasedresource consumption because of reduced surface friction, increasedrolling resistance, and increased use of climate control and defrostingsystems. Numerous variations are envisioned depending on the types ofweather data collected by weather data collector 70 and the types ofresources vehicle 21 has available that may be affected such as a mainbattery, super capacitor, fuel cells, or a supply of fossil fuel to namea few. Other embodiments of weather model 107 are envisioned as wellincluding models correlating points along each route segment or partialsegment with specific predicted levels of battery energy, fossil fuel,or other resources remaining at each point as well as an indication ofthe accuracy of the prediction. The resulting weather model 107,whatever form it may take, can be saved to data store 50 to facilitatefurther probability calculations and later data analysis.

A traffic model 111 may be generated (90) and stored in data store 50 aswell. Traffic model 111 can include values derived from data collectedfrom any available source including traffic data collector 73, thevalues representing changes in resource usage in relation to trafficflow. In one example, the route may be divided into segments andresource consumption for each individual segment may be calculated basedon current traffic patterns. If, for example, data collected by trafficdata collector 73 indicates a 75 percent chance that one segment of oneof the routes currently under consideration will be completely blockedfor thirty-five minutes by excessive traffic before the vehicle can passthrough the area, then the resulting traffic model 111 might indicate a75 percent chance of increased fuel usage and a corresponding reductionin efficiency due to the extra fuel burned at a decreased rate oftravel. On the other hand, if vehicle controller 34 were performing thispredictive calculation while currently in a traffic jam, the trafficmodel 111 generated at 90 might indicate an increased likelihood ofsuccess due to more efficient use of resources over the remainder of theroute.

Another example of traffic model generation 90 generates a resourceconsumption profile by segmenting the route according to traffic usageand then calculating a range of battery, fuel, or other resource usagesrelated to past traffic patterns along with the probability and extentof resource usage for each segment. These values would be stored in datatables in traffic model 111 and saved to data store 50 after creation at90 for later use and processing.

A map model 113 is generated (92) using various map data such as datacollected by map data collector 62 as well as from other sources andsaved to data store 50. In one example, map model 113 is generated toinclude one or more maps that may be used to correlate location datareceived from location data collector 60 with one or more possiblelocations of interest, past destinations, and potential newdestinations. Map model 113 can be used to organize relevant nodesrepresenting geographic locations, and connecting paths or path segmentsrepresenting streets, roads, or other paths that may be traversed by thevehicle. Map model 113 may also include polygonal or other similarrepresentations of regions to be traversed or avoided during a trip ortrips. This polygonal or other representation of a region may betwo-dimensional (e.g. an area), or three dimensional (e.g. a volume)indicating variations in height or altitude as well as relativelocation. Thus map model 113 may be used to maintain an electroniccomputational representation of the region the vehicle route passesthrough that may be useful for other calculations. Map model 113 mayinclude rendered images of the area to be traveled that may be renderedby processor 46, or obtained from a remote server and stored in datastore 50. These rendered images may be displayed before, during, andafter the trip on user interface 37, or on another display such as on adisplay coupled to a remote server analyzing the results of a given setof data retrieved by analytics agent 53.

At 95, a topography model 116 can also be generated. Topography model116 can be used to organize topography data from various sourcesincluding data collected by topographical data collector 64. One exampleof generating a topography model (95) includes segmenting the one ormore chosen routes based on changes in grade. For example, a segment ofthe route may be generated for typography model 116 where the grade forthat segment is 1 percent. In this example, a new segment is createdwhen the grade changes by some predetermined differential such as bygreater than a tenth of a percent, greater than a half percent, or bygreater than a one percent. Therefore stretches of the selected routehaving changes in grade of less than the predetermined differential arecalculated as if they had substantially no change in grade. In thisexample of topography model 116, longer segments can be calculated forflatter sections and hilly sections of the route can be broken intonumerous shorter segments. Long steady climbs and descents may then alsoappear as large single segments where the path has substantially thesame grade (positive or negative) throughout the segment. With the routemodeled in terms of changes in grade, each segment of the route can beassigned resource parameters indicating the resource usage required tonavigate each segment due to the typography of that segment.

In another example, a topography model 116 is generated at 95 bysegmenting the route based on changes in altitude. In this example, anew segment is created when altitude changes by a predetermineddifferential such when the altitude changes by more than 5 feet, morethan 15 feet, more than 25 feet, or more than 75 feet. This embodimentof topography model generation 95 essentially generates a topographicaldata map of elevational changes over the selected route in topographymodel 111 and assigns resource drain or usage parameters to each segmentindicating the resources required to navigate a particular segment dueto the change in altitude occurring within that segment.

Other techniques for segmenting the route according to topography arealso envisioned as well to facilitate a detailed computational analysisof how much energy is required to traverse the route. Information storedin topography model 111 can include data indicating how much energy, ifany, can be harvested from the vehicle's regenerative braking systems,if available. This includes a prediction regarding at what times orlocations during the trip, if any, the vehicle's primary battery willbecome temporarily unable to take further charging due to overheating,temporary overcharging, and the like. For those portions of the tripwhere the battery is unavailable for charging, regenerative braking maynot be relied on for supplying energy to extend the vehicle's range andthis possibility can be factored into topography model 111. At any rate,topographical information used in calculating a result is represented intopography model 111 and saved in data store 50 for later processing.

A probability of successfully reaching the intended location can becalculated when some or all of driver specific parameters 100, vehiclestate 103, weather model 107, traffic model 111, map model 113, andtopography model 116 have been generated. For example, as illustrated inFIG. 3, the initialization (80), reading of driver specific parameters(83), reading of vehicle state (85), and the generation of weather,traffic, map, and topography models (88, 90, 92, and 95) may occur as aseparate data update cycle or data update control loop operatingrepeatedly without intervention by the user, optionally even occurringwhen no particular probability calculations have been requested. Thisseparate operational loop provides for the most recent data models 107,111, 113, 116, 119, as well as the most recent vehicle state 103 anddriver specified parameters 100 to be used in any probabilitycalculations that may be initiated.

FIG. 3 is illustrative only in that updates occurring in this separatedata update cycle may occur as shown in a particular sequence, or theymay operate synchronously or asynchronously in parallel, or in anycombination of sequentially or in parallel. For example, the reading ofdriver specific parameters 83 may be initiated at the same time as thereading of vehicle state 85, the generation of a weather model 88, thegeneration of a topography model 95, etc. No particular order isrequired, and it may be advantageous to execute one or more of theseactions in parallel, for example in a multi-threaded environment onseparate processing cores or other processing hardware in the same orseparate integrated circuits. It may, for example, provide a better useof processor 46 to read driver specific parameters (83) once a second,while generating a new weather model (88) at a slower rate, perhapsevery 10 minutes given that weather may tend to change more slowly thandriver preferences. In another example, it may be advantageous to readthe vehicle state (85) a thousand times a second, while generating a newtraffic model only every 5 minutes as it may be more likely for thevehicle state to change substantially faster than the flow of trafficalong the route ahead, or along other possible routes. These are but afew examples as there are numerous possible variations on the timing ofactions taken involving acquiring and processing data stored in datastore 50.

The probability of successfully reaching a final destination may berequested (120) resulting in a final result 119, preferably after datastore 50 contains at least some of the data discussed above. Driverspecific parameters 100 are processed at 123, as well as vehicle stateinformation 103 at 125. Data from weather model 107 is processed at 127,traffic model 111 at 129, map model 113 at 132, and topography model 116at 135 and a final result 119 is calculated at 137. Various types ofprocessing are considered, as well as various alternatives related totiming of the actions shown in FIG. 3

In one example, calculating a final result 137 calculates whether thevehicle has sufficient resources to reach the one or more destinations(either selected by the user or by controller 34) by processing theprobability of success with respect to route data modeled in weathermodel 107, traffic model 111, map model 113, and topography model 116.The current vehicle states 103 and driver specific parameters 100 may beused as a starting point for current calculations. In this example, thecalculations may proceed by considering each segment of each model andcalculating the probable gain or loss in remaining resources such asbattery energy, fuel, etc., and logging reasons for those predictedgains and losses. The gains and losses can be organized according to thevarious vehicle systems and subsystems across the various data modelsthus allowing the probability of success for the entire trip to becalculated. In this type way, complexities may be broken down, analyzed,and resolved providing additional accuracy that simpler processingsystems may not be able to offer.

For example, the user may have initiated the probability calculationfrom atop a mountain having a half charged battery seeking home as afinal destination. Topography model 111 might indicate a net gain incharge over several segments of the trip and the reason attached to thatresult might be, for example, battery charging from regenerative brakingresulting from steady, high speeds due to unobstructed, extendednegative grades. Given the vehicle's regenerative charging abilities,this alone might be sufficient to yield a high probability ofsuccessfully reaching the final destination. However, when factoring inthe traffic and weather models for these same segments with longdownhill grades, it might be found that the road is covered with ice andthe vehicle must travel much slower than normal. Because harvestingenergy from the vehicle's regenerative charging abilities is no longeran option due to lower speeds, the result may be a low probability ofsuccess without stopping to recharge first.

In another example, a simple calculation of distance to the finaldestination during daylight hours may indicate that vehicle 21 hasenough fuel or battery charge to reach the destination. However, whenweather model 107 is processed at 127, it may indicate that for thefirst half of the journey, heavy rain is expected reducing fuelefficiency and requiring the operation of resource draining devices suchas HVAC defroster, windshield wipers, and headlights. Processing oftraffic model 111 at 129 may also indicate that for the first half ofthe journey, traffic is expected to be slow-moving because of the rainand time of day. Processing of map model 113 at 132 may also indicatethat for the second half of the journey, refueling or rechargingstations are unavailable, although they are plentiful throughout thefirst half of the trip. It may also show that the first half of theroute includes some traffic lights which are not timed and thereforestop and go traffic can be expected. When topography model 116 isprocessed at 135, it may show that the first half of the route issubstantially flat with only small changes in grade, and the second halfincludes several long uphill grades resulting in substantial changes inelevation.

In the final result calculation 137, for example, an initial calculationusing driver specific parameters 100, and vehicle state 103 mightindicate a high probability of successfully reaching the finaldestination, perhaps 95%, given that the vehicle has enough fuel and orbattery charge to make the trip. The calculations of weather model 107at 127 and traffic model 111 at 129 would reduce this probabilitybecause of reduced speeds and increased resource consumption per milebecause of bad weather resulting in a probability of success of perhaps50%. The topography model 116 processed at 135 would further reduce thisprobability of success to perhaps 1% because of the increased resourceconsumption required for long uphill grades. Map model 113 processed at132 may increase this probability back to about 95% by noting in thefinal result that a high probability of reaching the final destinationcan be achieved if vehicle resources are replenished at a refueling orrecharging station near the end of the first half of the trip. Severalsuch stations may then be retrieved from map model 113, or map dataavailable in data store 50 or remotely for inclusion in final result119.

In some examples, all models may have the same route segment size, whilein others, the models may have differing route segment sizes. In oneexample, the segment size is the entire route. In this example, thesuccess or failure of reaching the final destination includes an averagecalculation of the individual probabilities calculated at 127, 129, 132,and 135 based on each specific type of input 100, 103, 107, 111, 113,and 116 (and any others). The overall probability of reaching thedestination given the current vehicle state 103 and driver specificparameters 100 may then be weighted more heavily toward a particulardata model such as weather model 107, topography model 116, and thelike. These are but a few non-limiting examples of scenarios under whichvarious positive or negative factors can be overcome be calculated byprocessor 46 and controller 34 in calculating the likelihood of vehicle21 successfully arriving at the selected final destination.

It should be noted that like the actions taken to generate variousmodels discussed above (e.g. 80, 83, 85, 88, 90, 92, and 95), theprocessing of vehicle state and driver parameters (125 and 123), as wellas the final result calculations performed by processor 46 (e.g. 123,125, 127, 129, 132, and 137) may be performed in any suitable order, andmay be performed at any time with respect to one another. FIG. 3illustrates a sequential flow, but such a flow should not be alimitation implied by the figure, only an illustration of one example ofhow the procedures may be executed in processor 46. In another example,all the actions taken in the final result calculations 123-137 mayexecuted in parallel, or in multiple threads at substantially the sametime within processor 46, or individually on one or more processingunits or processing cores at substantially the same time withinprocessor 46. In another example, processor 46 may include individualprocessing units for each type of data model (e.g. a processing unit forweather model 107, a second processing unit for traffic model 111,etc.), with each individual processing unit enclosed in the same housingor package as part of the same removable circuit, or with eachprocessing unit in separate housings or packages on separate integratedcircuits or circuit boards.

Like model calculations discussed above, it may be advantageous toprocess models from data store 50 at significantly varying rates. Forexample, it may be advantageous to process traffic model 111 (at 129)once every 5 minutes or more, while processing vehicle state 103 (at125) a thousand times a second, or more, or perhaps ten thousand times asecond or more. This arrangement may be likely for traffic patterns tovary far more slowly than the state of vehicle 21. Similarly, it mayonly be advantageous to process topography model 116 (at 135) at two orthree intervals calculated by processor 46 like after about 33% and 66%of the route have been traversed given that topography model 116 may notinclude data that is likely to change very often. Any suitable timing ofmodel processing or the calculation of final result 119 is envisioned.

Final result 119 may be displayed or otherwise indicated on userinterface 37 for user 36. Controller 34 updates the user interface (140)with a final result 119 resulting in the probability being updated (143)and completion of the request for an update (120). Various embodimentsof user interface 37 are envisioned. One embodiment of user interface 37displays the probability of successfully reaching the desireddestination by the route selected as a number on a visual display.Another embodiment of user interface 37 indicates multiple routes to thedesired location, and the probability of successfully completing eachroute. This probability may be indicated using colors, symbols, shapes,graphs, and any other suitable indicia.

If the probability of reaching the destination is below a predeterminedthreshold for any of the routes, user interface 37 may read the finalresult 119 to determine if any reasons were indicated as to why finalresult 119 includes a low probability of success. These reasons may thenbe reformulated and presented to the user as a list of one or moreoptions for decreasing the use of resources such as battery energy orfuel. The user may then select or deselect the options and the userinterface may then adjust the chance of successfully reaching thedestination. For example, the final result 119 may indicate a 20%probability of successfully reaching the destination for a given routewith options including turning off the air conditioner, heater, stereo,rear window defroster, seat heaters, head lights, cabin lights, radarcollision avoidance system, or rear seat entertainment center. Turningoff some or all of these vehicle systems might then raise theprobability of success to 85%. The user may accept the route with themodified options list, which can result in controller 34 activating ordeactivating these and other vehicle features and accessories usingvehicle control interface 41.

Another embodiment of user interface 37 offers the user options to turnoff the heater, heat lights, stereo, etc., while displaying next to eachitem the probability of successfully reaching the destination if thatvehicle feature were to be disabled for the remainder of the trip. Thismay require calculating the probability of success (FIG. 3 at 120) onceas if each feature were enabled, and again as if corresponding featureswere disabled, thus providing an accurate comparison of the results theuser can expect from making different selections. This embodiment mayalso flash a warning message during the trip if the disabled accessoriesis re-enabled.

Another example of user interface 37 allows the user 36 to use processor46 to recalculate a range of probabilities of successfully completingthe trip for a given route as a function of average speed. Userinterface 37 may display a curve, graph, or series of selectors showingspeed vs. probability of success and allowing the user to select thecombination of speed and probability suitable to the present situation.This speed may then be saved in vehicle controller 34 as an averagespeed and if vehicle 21 nears or exceeds this speed during the journey,user interface 37 can warn the user to reduce speed to save fuel orbattery energy. A similar embodiment allows the user to calculate arange of probabilities for a given route as a function of frequency ofabrupt acceleration or “aggressiveness.” The user selects a calculatedprobability from the list supplied and then if the user acceleratesrapidly too often, user interface 37 may warn user 36 that resources arebeing consumed too rapidly to reach the desired destination.

In another example, user interface 37 displays a color-coded map of theroute with colors corresponding to higher or lower resource consuminglocations or “hotspots” as indicated by weather model 107, traffic model111, map model 113, and topography model 116. The user can selectivelyview information from each model overlaid on the route individually orin aggregate. This view of the modeled data offers insights regardingareas along the route that are particularly taxing on vehicle resourcesor offers clues as to how the driver may be able to alter the route,time of day the route is traveled, or other variables to achieve adifferent result.

In yet another example, user interface 37 offers user 36 a display withresource replenishment options such as charging stations, fuel stations,and the like for those situations where the vehicle likely cannotcomplete the journey before charging the battery, refueling the vehicle,or both. User interface 37 may give directions, maps, or both to nearbycharging stations as well as map, location, and contact information formobile charging service vehicles currently operating in the area. Userinterface 37 may also indicate the approximate additional time added tothe trip due to the need for additional fuel, battery energy, or otherresources. It may also, for example, indicate how long vehicle 21 willneed to charge at each location to fully recharge (or refuel) given thata fixed charging station may have a different charging capacity than amobile one. However, this embodiment of user interface 37 also allowsthe user to specify a maximum charging time in cases where time islimited. User interface 37 respondents by initiating probabilitycalculations for each battery charging service available and updatesuser interface 37 with a display indicating the probability ofsuccessfully completing the entire trip after charging the battery ateach location for the available time entered by the user. These areseveral embodiments of user interface 37, but others are envisioned.

Vehicle controller 34 has the ability to refine and adapt itsprobability calculations over time by means of analytics agent 53. Oneembodiment of analytics agent 53 loads trip data from data store 50 forall previously recorded route segments the vehicle has calculatedprobabilities for and then actually traveled over and compares thecalculated probability of particular events occurring against the actualoccurrence of those events. These results can be used to gauge thestrength or weakness of current prediction algorithms and data sources.Another embodiment of analytics agent 53 connects to a remote dataservice through a network connection such as the internet or otherremote connection and uploads all recorded route segments the vehiclehas traveled and made probability calculations for since the last timeanalytics agent 53 uploaded data. Analytics agent 53 then waits a periodof time for a reply from the remote service and upon receiving it,downloads a response which includes a software upgrade that includesimproved algorithms yielding more accurate probability calculations.

As historical data is developed, it might be learned that for selectedvehicles and for selected routes, some of the algorithm variables have agreater weight or importance than others in terms of fuel usage orbattery life and utilization of the charge on the battery. It isimportant to allow some design freedom in this regard for the algorithm.The option of making the algorithm programmable with an electronicinterface enables refinements based on the most recent and most relevantdata.

In another aspect, vehicle controller 34 may include a dynamic brakingalgorithm 150 that controls the friction and regenerative brakingsystems of vehicle 21 in conjunction with or separately from the vehicleresource management algorithms disclosed above. Some embodiments ofvehicle controller 34 may include options allowing user 36 to separatelyand independently enable and disable the predictive calculationsdisclosed above and the dynamic braking functions.

FIG. 4 illustrates at 150 one example of the actions vehicle controller34 may take to manage the braking of vehicle 21. With the vehicle inoperation (151), braking algorithm 150 determines whether or not theoperator (for example, user 36) is applying the vehicle's accelerator(155). If so, braking is ignored and vehicle speed varies according tonormal vehicle operation (151). If the operator is not applying theaccelerator (155), the algorithm determines whether the operator isapplying the brakes (157) by, for example, measuring or detectingapplication of pressure to a brake actuating mechanism such as a brakepedal or brake lever configured to engage the braking system.

If the operator is applying the brake to reduce the speed of vehicle 21,the algorithm calculates braking force and energy recovery from the userinput (164). In one example, the braking force is a function of thedistance the brake pedal or lever is deflected by the user from anun-actuated or resting position to an actuated position. In anotherexample, the braking force is a function of the velocity of the brakepedal or lever as it is deflected at a particular rate from a resting orun-actuated position to a partial or fully actuated position over aperiod of time. In another example, both deflection and velocity areconsidered.

The amount of braking force is calculated, either by controller 34 or byvehicle 21 and the result is made available to controller 34, forexample, via vehicle control interface 41. The approximate amount ofenergy the vehicle is expected to recover as electricity (if any) fromregenerative braking is calculated based on the predicted amount ofbraking force. If the main battery or battery cells and chargingequipment in vehicle 21 has the available capacity to accept and storethis expected quantity of energy (169), controller 34 may activateregenerative braking to an extent proportional to the braking forcecalculated based on user input at 164. The result is a negative vehicleacceleration and possibly decreasing speed as energy is converted fromvehicle kinetic energy through the wheels and vehicle drive train toelectrical energy stored in a main battery or similar electrical storagedevice. Vehicle operation continues at 151 where braking andacceleration can be recalculated a new.

Energy storage is available in situations where vehicle 21's mainbattery is in a condition to receive energy. In some cases the batterymay not be able to accept energy from further charging due to variousconditions such as excessive battery heating due to recent charging orexcessive momentary battery drain, or the main battery's inability toreceive or maintain a charge because of age or deterioration, and thelike. If other electrical energy storage devices are available such as,for example, super capacitors, the status and capacity of these devicescan be determined as well at 169 allowing for them to possibly receive acharge as well.

If energy storage is not available (169), such as, for example, invehicles not equipped with operating regenerative braking systems, or invehicles where the main battery is unable to receive an additionalcharge, the algorithm activates a friction braking system to providebraking force approximately equal to the braking force calculated basedon user input (164) as described above. The friction braking systemapplies friction to the wheels, usually indirectly through a disc orrotor coupled to the wheel and slowed by friction induced by padspressed against the disc or rotor. This also results in negativeacceleration and possibly a speed reduction. In this scenario, thevehicle operator explicitly applied the brakes (157) indicating somequantity of braking such as by deflecting a lever or pedal as describedabove. This causes dynamic braking algorithm 150 to activate thevehicle's friction braking system (175) after determining that noelectrical energy storage capacity is available (169) causing thekinetic energy of vehicle 21 to be dissipated in some other way, such asthrough heat caused by friction. The resulting negative accelerationcaused by applying the brakes at 157 is therefore approximately the sameregardless of whether the regenerative braking system is activated (172)or the friction braking system is activated (175).

In some embodiments of algorithm 150, the system may execute theillustrated series of actions several hundred or thousands of times asecond during braking, and may switch between regenerative and frictionbraking as vehicle 21 loses speed and it becomes possible toregeneratively brake or necessary to friction brake. In another exampleof algorithm 150, regenerative braking may be performed (172) so as toprovide as much electricity as the storage batteries or charging systemmay be able to handle while also activating friction braking 175 toprovide additional braking so that both regenerative and frictionbraking combined provide braking force about equal to the requestedbraking force calculated based on user input (164).

If, however, the driver does not apply the brake at 157, the algorithmmay then determine the probability of a stop at 159. In one example,algorithm 150 compares vehicle 21's location to the known locations ofstopping points along the vehicle's route which may be saved in mapmodel 113, for example. Stopping points may be determined by examiningmap data collected from previous trips over the same route and recordingpoints at which the vehicle came to a stop, or slowed to a speed below apredetermined “stopped” threshold along the same route in past trips.Areas where the vehicle came to a stop only once or twice duringprevious trips may be ignored as outliers resulting from anomalies inthe traffic flow such as vehicle breakdowns, temporary obstructions inthe road, variations in weather, and the like. The remaining points maybe considered likely stopping points and can be compared with thecurrent location of vehicle 21 as determined by GPS or map data in datastore 50, or other similar location finding technology.

In another example of dynamic braking algorithm 150, stopping points maybe determined from map data in data store 50 downloaded from a remotedatabase like those described above which may indicate where stoplights,stop signs, heavy traffic, construction zones, and various other roadobstructions are likely to appear or are permanently in place. Inanother example, dynamic braking algorithm 150 combines previous routehistory with remotely obtained map data to determine likely stoppingpoints along the route. In another example, braking algorithm 150 mayalso consider weather, topography, and traffic data in determining theprobability of a stop (159), as well as map data and previous drivinghistory.

If the probability is equal to or greater than a predetermined brakingthreshold, and therefore the algorithm determines braking is needed(161), dynamic braking algorithm 150 calculates braking force and energyrecovery resulting from the braking force from the accumulated data(167) in data store 50. In one example of calculating the braking forcefrom accumulated data (167), dynamic braking algorithm 150 selects apredetermined light braking pressure to apply to the braking system, andthen applies regenerative (172) or friction braking (175) accordingly,and recalculates beginning at 151. In another embodiment, dynamicbraking algorithm 150 determines the degree of braking force to beapplied by calculating negative deceleration that is inverselyproportional to the distance to the next stopping point known. Ifalgorithm 150 determines the next stopping point is close, dynamicbraking algorithm 150 selects a significantly higher braking force toapply then if the distance between vehicle 21 and the next stoppingpoint is larger. Algorithm 150 may also select the braking force basedon an exponential, geometric, or logarithmic curve. For example, thealgorithm may select a value of 10 representing the braking forceselected when a stopping point is likely to be 100 feet away, versusselecting a value of 0.1 representing the braking force selected when astopping point is likely to be 1000 feet away, a value which may resultin almost no braking at all. In this example, one hundredth the brakingforce is applied for a stopping point ten times further away.

In yet another example, vehicle speed, the probability of a stop, andthe distance to the likely stopping point may all be evaluated tocalculate a value representing the selected braking force. In thisexample, exponential, logarithmic, or geometric curves may be used toadjust the selected braking force so that, for example, the brakingforce selected at a high rate of speed for a stopping point that isnearby will be proportionately much higher than the braking forceselected for a lower speed or a stopping point likely to be furtheraway. Driver specific parameters 100 may include values for settingwhether algorithm 150 should optimize its selection of braking forcebased on recovering the maximum available vehicle kinetic energy(possibly resulting in a less comfortable ride), or providing a smoothdriving experience for the operator and passengers, or some valueselected along a gradient between these and possibly other extremesettings. For example, if optimized for maximum energy recovery, vehicle21 may decelerate more sharply by applying regenerative braking to agreater extent upon lifting the accelerator rather than letting vehicle21 coast with little or no braking as it might if optimized for asmoother ride.

The selected braking force can be used to calculate the energy that maybe recovered (167) and algorithm 150 using processor 46 may execute theremaining actions of determining how much energy storage is available(169), and applying regenerative braking (172), friction braking (175),or both as discussed above, causing vehicle 21 to experience a negativeacceleration and possibly reduction in speed. If the probability of astop is below a predetermined braking threshold, and braking isdetermined to be unnecessary (161), no vehicle braking is activatedleaving vehicle 21 to operate normally (151) gaining or losing speedwithout any intervention by the vehicle's braking system.

Another example of algorithm 150 is illustrated in FIG. 5 where dynamicbraking algorithm 150 receives vehicle proximity data from proximitysensors (for example radar, laser, ultrasound, and the like) located onvehicle 21 which indicate how far away local vehicles are from vehicle21 ahead, behind, to either side, or to any corner of the vehicle aswell if so equipped. In this embodiment, dynamic braking algorithm 150operates as discussed above, except the determination of whether brakingis needed (192) is based on (or in addition to) calculating the rangeand closure rates with respect to local vehicles (190).

In one example, algorithm 150 selects a braking force that is inverselyproportionate to the speed of vehicle 21, and the distance betweenanother vehicle in front of or behind vehicle 21. A linear, exponential,logarithmic, geometric, or other formula may be used to select thebraking force. Algorithm 150 may include in its calculations thedistance between vehicle 21 and other nearby vehicles as well as thespeed differential between vehicle 21 and nearby vehicles. For example,if vehicle 21 is traveling at a high rate of speed, such as on a limitedaccess divided highway, where the nearest other vehicle is a thousandfeet ahead, minimal if any braking may be selected by algorithm 50 whenno accelerator input is provided by the user (155). However, if in thisexample vehicle 21 has another vehicle 10 feet ahead of it (moving at asimilar high rate of speed), then not applying the brake (157) mayresult in perhaps 500 or 1000 times more braking force being selected,or even more, causing a substantial reduction in speed to create a morerapid separation from the nearby vehicle I had. On the other hand, ifthe other vehicle is 10 feet behind vehicle 21, perhaps only 5 times, 10times, or 25 times the braking force may be selected when the operatorlifts the accelerator (155) to avoid causing a rear end collisionresulting from a substantial reduction in the speed of vehicle 21. Aswith previous values, these values are not restrictive but exemplary asmany other values may be selected depending on the particularimplementation of algorithm 150, the type of vehicle, and the valuesused to express the level of braking to be applied among other things.

In another example, calculating range and closure rates (190) takes intoconsideration vehicle attitude, that is the angle of inclination ordescent, of vehicle 21 when it is coasting along with the resulting rateof acceleration or deceleration. In situations where vehicle 21 isclimbing a hill, this embodiment of dynamic braking algorithm 150 canfactor in the positive grade when calculating closure rates (190) aswell as when calculating how much braking force to generate (196) giventhat the inclined road surface itself will provide assistance instopping vehicle 21. Likewise, if vehicle 21 is accelerating because ofa declining road surface, dynamic braking algorithm 150 will be morelikely to apply greater braking pressure if a stop is near or a vehicleahead is closing quickly because the speed and or acceleration of thevehicle may require a more substantial speed reduction over a shorterperiod of time to maintain control of the vehicle and avoid collidingwith local vehicles in the immediate vicinity. Various other embodimentsare envisioned as well these illustrative examples.

In yet another example, the closure rate of local vehicles near tovehicle 21 is calculated and evaluated in selected a braking force alongwith, or instead of, the distance to the local vehicles. For example, avehicle ahead of vehicle 21 with a high closure rate may mean a largerbraking force is selected by the algorithm. In another example, avehicle behind vehicle 21 with a high closure rate may mean little ifany braking force is preferred to avoid an accident.

The selected braking force can be used to calculate the energy that maybe recovered (196), and the remainder of algorithm 150 can execute theactions of determining how much energy storage is available (169), andapplying regenerative braking (172), friction braking (175), or both asdiscussed above, applying a negative acceleration to vehicle 21. If theproximity and closure rates of local vehicles is such that braking isnot needed (192), no vehicle braking may be activated leaving vehicle 21to coast gaining or losing speed without intervention from the vehicle'sbraking system.

While the invention has been illustrated and described in detail in thedrawings and foregoing description, the same is to be considered asillustrative and not restrictive in character, it being understood thatonly the preferred embodiment has been shown and described and that allchanges, equivalents, and modifications that come within the spirit ofthe inventions defined by following claims are desired to be protected.All publications, patents, and patent applications cited in thisspecification are herein incorporated by reference as if each individualpublication, patent, or patent application were specifically andindividually indicated to be incorporated by reference and set forth inits entirety herein.

What is claimed is:
 1. A resource management system comprising: avehicle located at a current location having a vehicle drive systemincluding energy storage means, the vehicle providing one or moreoperating parameter values indicating the operational state of thevehicle, the vehicle accepting one or more control values forcontrolling the consumption of one or more vehicle resources; a userinterface configured to accept input from a user representing adestination, and one or more trip variables corresponding to the rate ofconsumption of one or more vehicle resources consumed by the vehicle inoperating the vehicle to reach the destination; and a controller havinga processor, the controller responsive to the vehicle and the userinterface and accepting the operating parameter values, the tripvariables, and one or more external data values from one or moreexternal data sources, the processor calculating one or more controlvalues provided to the vehicle, and at least one success probabilityrepresenting the probability of the vehicle successfully completing theintended route.
 2. The resource management system of claim 1, whereinthe processor calculates the one or more control values by calculating aroute between the current location and the destination, dividing theroute into at least two segments, calculating at least two correspondingsegment probabilities indicating the probability of successfullytraveling through the corresponding at least two segments, and computingthe at least one success probability based on the at least twocorresponding segment probabilities.
 3. The resource management systemof claim 2, wherein the one or more external data values represent oneor more environmental conditions, and wherein calculating the at leastone success probability includes calculating changes in vehicleresources by calculating a predicted change in vehicle resources basedon the one or more operating parameter values, the external data values,and the trip variables.
 4. The resource management system of claim 3,wherein the external data values include map data values representingone or more locations, and one or more paths between locations, thelocations and paths corresponding to geographic locations and travelpaths.
 5. The resource management system of claim 4, wherein theexternal data values include topography data values representingelevation changes between the current location and the destination. 6.The resource management system of claim 5, wherein the vehicle drivesystem includes an internal combustion engine.
 7. The resourcemanagement system of claim 1 wherein the one or more external datavalues represent one or more environmental conditions.
 8. The resourcemanagement system of claim 1 wherein the external data values includemap data values representing one or more locations, and one or morepaths between locations, the locations and paths corresponding togeographic locations and travel paths.
 9. The resource management systemof claim 1 wherein the external data values include topography datavalues representing elevation changes between the current location andthe destination.
 10. The resource management system of claim 1 whereinthe vehicle drive system includes an internal combustion engine.
 11. Theresource management system of claim 1 wherein said energy storage meansincludes electrical storage means and/or chemical storage means and/ormechanical storage means.
 12. A vehicle braking system comprising: avehicle located at a current location having a friction braking systemand a vehicle drive system including energy storage means operating aspart of a regenerative braking system, the vehicle providing one or moreoperating parameter values indicating the operational state of thevehicle; and a controller having a processor, the controller responsiveto the vehicle, the controller accepting the operating parameter valuesand one or more external data values from one or more external datasources, the processor calculating one or more braking controlparameters for optimization of the regenerative braking system tomaximize stored energy while safely operating the vehicle.
 13. Thevehicle braking system of claim 12, wherein the processor calculates theone or more braking control parameters using one or more external datavalues representing the location of predicted stopping points, theprocessor calculating one or more braking control parameters andapplying a braking force which optimizes stored energy based on thedistance to the next predicted stopping point.
 14. The vehicle brakingsystem of claim 13 further comprising one or more vehicle sensorsresponsive to one or more nearby vehicles, the controller responsive tothe vehicle sensors, wherein the processor calculates one or morebraking control parameters and applies a braking force which optimizesstored energy while maintaining a desired separation distance betweenthe vehicle and at least one nearby vehicle.
 15. The vehicle brakingsystem of claim 13 wherein the processor calculates one or more brakingcontrol parameters and applies a braking force based on closing speeddifferential representing the difference between a current vehicle speedand a speed of at least one nearby vehicle to optimize energy storagewhile safely operating the vehicle.
 16. The vehicle braking system ofclaim 12, wherein the processor calculates the one or more brakingcontrol parameters using one or more external data values representingthe location of predicted stopping points, the processor calculating oneor more braking control parameters and applying a braking force whichoptimizes stored energy based on the current speed of the vehicle. 17.The vehicle braking system of claim 16, further comprising one or morevehicle sensors responsive to one or more nearby vehicles, thecontroller responsive to the vehicle sensors, wherein the processorcalculates one or more braking control parameters and applies a brakingforce which optimizes stored energy while maintaining a desiredseparation distance between the vehicle and at least one nearby vehicle.18. The vehicle braking system of claim 16 wherein the processorcalculates one or more braking control parameters and applies a brakingforce based on a closing speed differential representing the differencebetween a current vehicle speed and a speed of at least one nearbyvehicle to optimize energy storage while safely operating the vehicle.19. The vehicle braking system of claim 12, further comprising: one ormore vehicle sensors responsive to one or more nearby vehicles, thecontroller responsive to the vehicle sensors; wherein the processorcalculates one or more braking control parameters and applies a brakingforce which optimizes stored energy while maintaining a desiredseparation distance between the vehicle and at least one nearby vehicle.20. The vehicle braking system of claim 19, wherein the processorcalculates one or more braking control parameters and applies a brakingforce based on a closing speed differential representing the differencebetween a current vehicle speed and a speed of at least one nearbyvehicle to optimize energy storage while safely operating the vehicle.21. The vehicle braking system of claim 12 wherein said processorcalculates one or more braking control parameters based on one or moreexternal conditions such as temperature, wind and moisture foroptimizing energy storage while safely operating the vehicle.
 22. Thevehicle braking system of claim 12 wherein said energy storage meansincludes electrical storage means and/or chemical storage means and/ormechanical storage means.
 23. A vehicle power control system comprising:a vehicle located at a current location having a vehicle drive systemincluding an energy storage device as part of a regenerative brakingsystem, the vehicle providing one or more operating parameter valuesindicating the operational state of the vehicle; and a controller havinga processor, the controller accepting the operating parameter values andone or more external data values from one or more external data sources,the processor being constructed and arranged for calculating one or morepower control parameters for controlling the activation of the vehicledrive system for the purposes of predicting future demand and safelyminimizing total energy expenditure.